Configuring the security subsystem

Starting with GeoServer 1.6.0 the GeoServer security subsystem has been improved by integrating Acegi, a library that allows for taking care or various security issues in web applications. The library itself is very powerful, thought due to development time constraints we're using just a few of its functionalities.

The current version of the security subsystem uses two plain text property files located in the GeoServer data directory to configure users and access permissions.
At the time of writing there is no web UI to edit those file contents, so you'll have to alter them by hand using a text editor.

The first file, GEOSERVER_DATA_DIR/security/user.properties, defines users, their password, and their roles. An example follows:

admin=geoserver,ROLE_ADMINISTRATOR
wfst=wfst,ROLE_WFS_READ,ROLE_WFS_WRITE
wfs=wfs,ROLE_WFS_READ

Passwords are kept clear text because there is no utility to edit the file that could handle password encription transparently, yet Acegi allows for using different password encrypters easily (so stay tuned for a version of Geoserver with UI editing and password encryption).
Roles are just strings starting with ROLE_, they are mostly free form. In the current implementation, ROLE_ADMINISTRATOR is the role required to access the web administration console, and it the only "well known" role, the others you'll have to make up to control access to services..

The second file, GEOSERVER_DATA_DIR/security/services.properties, states which services are secured, and which roles the user must have in order to access them. For example:

wfs.GetFeature=ROLE_WFS_READ
wfs.Transaction=ROLE_WFS_WRITE

Service security configuration requires a service.method or simply a service key, and a list of roles that can access that service or method. A user having at least one of those roles will be able to call that method. When invoking an service method, the dispatcher will check if there is any service.method role configuration, if none is found, a service configuration will be looked up, and if again none is found, the service will be assumed to be non secured so no password is required.

Accessing secured services

The web console is accessed by means of a form based authentication, with optional remember-me cookie setting.
The services are secured using HTTP BASIC authentication, which is to be provided on each call.
The form based authentication is in fact session oriented, and if the same browser is used to access OWS services as well, the authentication will be remembered.
As a rule of thumb, accessing a secured resource now follows this process:

• if any authentication information is included along with the resource access, it will be used, and in the case of form based one, a session will be created to store it, whilst in the BASIC authetication case, session integration will be performed only if a session is already available (session creation is avoided for service call to avoid its overhead)
• if no authentication is provided, anonymous login will be assumed
• if the resource being accessed is secured and the current user is anonymous, authentication will be requested either using BASIC authentication (for OWS services) or by using form based login (for the web console)
• if the resource begin accessed is secured and the currently authenticated user has not enough rights to access it (access roles missing) an HTTP 404 error will be returned.

To allow for authorization quick tests, the "sample request" page now provides (optional) username and password fields that will be turned into a HTTP BASIC authentication header.

Disabling the security subsystem

If you are already using an external security subsystem it might conflict with the GeoServer one. The only option at the moment is to disable completely the GeoServer one and rely only on the external one.
Beware, this means you'll have to make sure the external one locks down the administration area, if you follow these instructions no password will be required anymore to enter the admin section.

To disable GeoServer Acegi integration:

• unpack the GeoServer war
• open web.xml
• comment out the "Acegi Filter Chain Proxy" filter definition and filter params like this:

  <!--  If you want to use your security system instead of the GeoServer one, comment out
           this filter and the associated filter mapping below. Beware, when you do no 
           user checking will be done for anything, not even for the admin console
     <filter>
       <filter-name>Acegi Filter Chain Proxy</filter-name>
       <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
       <init-param>
         <param-name>targetClass</param-name>
         <param-value>org.acegisecurity.util.FilterChainProxy</param-value>
       </init-param>
     </filter>
      -->
  
    ...
  
    <!-- If you want to use your security system comment out this one too
    <filter-mapping>
      <filter-name>Acegi Filter Chain Proxy</filter-name>
      <url-pattern>/*</url-pattern>
    </filter-mapping>
     -->

Then redeploy GeoServer, the security subsystem should be completely off, and access to the amin area should be free of password requests. Now your job is to setup whatever external security you have to protect the admin area (hint, the admin area pages are located at http://host:port/geoserver/config/*).